1. Field of the Invention
The present invention relates generally to data interchange, and more particularly to methods for establishing a persistent and stable communication connection.
2. Related Art
Whenever two or more people are involved in the preparation of a document, whether it be a financial spread sheet, a CAD design, a circuit schematic layout, an organization report, a bit map image, etc., succeeding drafts of the document are prepared, circulated, and modified in the process. Each person annotates his or her remarks on the document and forwards it to the next person. Typically, several drafts of the document will be circulated before a final draft is produced. This is a very time-consuming process.
In the case where the reviewers involved in this document preparation process are at different geographical locations, getting the document from one location to another location and back becomes another tedious and time-consuming task. The document must be mailed or faxed to that person, further complicating the entire process.
One alternative method to this process is to hold meetings where the reviewers gather and comment on the document with the hope to reduce the number of drafts needed before a final draft is produced. The shortcoming with this method is that there may be significant travel time and travel cost in getting everyone to the same location. In addition, the final draft of the document is usually circulated again for final comments.
One solution to this problem is to use a teleconferencing software program to share the document among the geographically dispersed reviewers. This process is often referred to as xe2x80x9cdata conferencing.xe2x80x9d By using computer network connections, modem-connected phone lines, and the like, everyone can be connected via his or her computer. By using the teleconferencing software program, everyone""s computer screen displays the same document. In addition to using the software program and network or modem connections, conference calling over the voice phone lines or through the software program creates a dynamic and live atmosphere where everyone can participate in the discussion and refer to the document displayed on the screen.
A key step in enabling data conferencing is making the network connection. The network connection between all the participants needs to be persistent and stable. In addition, many companies protect their internal networks from the Internet by imposing firewalls that bar such persistent stable connections, which are considered to be security risks.
The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is however, a generic, stateless protocol and does not provide all the attributes that are necessary to enable a data conferencing session amongst multiple users or clients, but for this reason, it is permitted to pass most firewalls.
The present inventions is an apparatus, method and computer program product for emulating a persistent connection using http.
According to one embodiment, the method includes receiving an empty get from a first client; receiving a get from a second client, the get containing data to be sent to the first client; and sending a response to the first client, in response to the empty get, the response containing the data.
According to another embodiment, the method includes receiving, from a client, a get containing first data to be sent to an application server; sending the first data to the application server; sending an ack response to the client in response to the get; receiving a response from the application server, the response containing second data to be sent to the client; waiting for an empty get from the client; receiving an empty get from the client; and sending the second data to the client in response to the empty get.
According to another embodiment, the method includes receiving, from a client, a get containing first data to be sent to an application server; sending the first data to the application server; sending an ack response to the client in response to the get; receiving an empty get from the client; receiving a response from the application server, the response containing second data to be sent to the client; and sending the second data to the client in response to the empty get.
To achieve both of shorter respond time and low network traffic, the current invention implements the following techniques:
1. When a client has data to be sent, it sends an http request to the server. The server analyzes the request, and recognizes that the request is a data packet. The server then handles the data and immediately responds to the request.
2. The client receives the server""s response. If it has more data to be sent, then repeat step 1.
3. If the client has no more data, it still sends an http request to the server, but marks this packet as an empty packet. When the server receives this empty packet, it will hold this request instead of responding immediately.
4. When the server is holding a packet and it has data to be sent, it will respond to this packet and send data to the client. In this way, the respond time is decreased to a minimum.
5. The server can not hold a packet indefinitely. If the server does not have any data to be sent for a specific time (e.g. 30 seconds), it will still respond to this packet, and client will send a new http request to server immediately. With this technique, both the server and the client will know that the communication connection is alive.
6. When the server is holding a packet and client has data to be sent, the client will send another http request to the server with the data packet (Before doing this, the client may cancel the old http request to keep only one http connection). When the server finds that it received two http requests from the same client, it will respond to the older http request at once and handle the newer http request. In this way, both the server and the client can send data to each other without any delay, and redundant network traffic is decreased to a minimum.
7. Finally, multiple http requests may still be used simultaneously.
The HTTP protocol is based on a request/response paradigm. (See http://ww.ics.uci.edu/pub/ietf/rfc1945.html) A client establishes a connection with a server and sends a request to a server in the form of a request method, followed by a message containing request modifiers, client information, and possible body content. The server responds with a status line, including the message""s protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible body content. Current practice requires that the connection be established by the client prior to each request and closed by the server after sending the response.
If a persistent connection is required, as in the case of a collaborative data conferencing session, a client can start the connections contiguously or periodically. That means client sends an http request to server with some data, server respond to client with some data, then client sends another http request to server immediately or after a specific time. In this way, a bi-directional live connection is established.
In the case where higher performance is desired than what is available with a single http request, a client can send multiple http requests to server simultaneously to achieve higher performance.
Http connection does not provide guarantees regarding order or reliability. For a data conference to occur, both the client and the server must have the ability to handle sequencing, re-send, redundancy, etc to achieve a reliable and ordered live connection.
Whenever a client has data to be sent to the server, the client can initiate an http request to the server. At that time when the server receives the request, if the server has outgoing data, it can send it to the client via the http response. But when the client has no outgoing data, because it can not predict when data will come from the server, it can only send a http request to the server periodically (e.g. 5 seconds). In this period between receiving requests, when the server has data to be sent, the server must wait for the next http request for it to respond. So the shorter the period is set, the shorter the server""s respond time will be. But the burden on network and the server will be raised as well.